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(57) Abstract: Service provisioning in mobile terminals is provided through registering and transferring of application context, 
which permits substantially seamless transfer of application functionality across administrative service domains. An architecture for 
providing application context transfer may include access routers, transcoder proxy servers, and gateway routers. A mobile terminal 
served by a current access router creates an application context for a session and registers it with the current access router. Around the 
lime of handoff, the current access router transfers the application context to a new access router associated with a new administrative 
domain and a new access network- The new access router evaluates the application context and takes steps to provide application 
functionality for the mobile terminal and current sessions. These steps may include the use of a network entity, such as a transcoder 
1^ proxy server, to modify data for a session and thereby provide application functionalitY in the new administrative domain. 
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PROVISIONING SEAMLESS APPLICATIONS IN MOBILE TERMINALS 
THROUGH REGISTERING AND TRANSFERRING OF APPLICATION CONTEXT 

FIELD OF THE INVENTION 

(OIJ This invention relates generally to telecommunications networks. More particularly, 
the invention concerns systems and methods for enabling seamless network level 
mobility in telecommunications networks. 

BACKGROUND OF THE INVENTION 

[02] Mobile Internet access is becoming increasingly more popular in concert with 
improvements in wireless technologies and reduced costs for those technologies. 
Early mobile Internet access was limited primarily to uses such as sending email or 
checking stock quotes. These uses typically entail relatively short transmission 
sessions that are less sensitive to minor disruptions. As the popularity and 
technologies of mobile Internet access improve, so will the demands of the end users. 
As they stay coimected for longer periods, use many different applications, and hop 
across different access technologies and administrative domains during an ongoing 
session, end users will demand continuity of their Internet applications. In short, they 
will desire essentially seamless mobile Internet service from the end user perspective. 

[03] Providing seamless services, therefore, may be a critical issue for the success of 
wireless networks. In the context of providing Internet access services supported by 
the Internet protocol (IP), seamless IP-layer cormectivity is important for ensuring that 
a mobile terminal can hand off to a new access router with minimal disruption to the 
mobile terminars Internet connectivity. There are several known approaches to 
providing such IP cormectivity. One approach, known as mobile IP, describes a 
mechanism that allows packets to be routed through the Internet to a new access 
router when the mobile terminal changes its point of Internet access from a current 
access router to a new access router. This mechanism is described in Internet 
Engineering Task Force (IETF) Request For Comments (RFC) number 3220 (October 
1996) and draft-ietf-mobileip-ipv6-16.txt. According to this mechanism, af^er having 
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established link-layer connectivity with the new access router, the mobile tenninal 
typically engages in signaling the new access router in order to obtain its new care-of- 
address. When obtaining the new care-of-address, the mobile tenninal has acquired 
IP-level connectivity with the new access router so that the mobile tenninal can 
transmit and receive packets with the new access router. A fast handofT protocol 
enables forming the new care-of-address while the mobile terminal is still attached to 
the cmrent access router. As soon as the mobile terminal acquires link-layer 
connectivity with the new access router, the mobile tenninal can transmit and receive 
packets with the new access router. 

|04) Simply moving the mobile terminal's point of access to the Internet from the current 
access router to the new access router may not sufHce if the packet session supporting 
the appUcation requires additional features such as transport quality of service (QoS), 
security, and header compression. These features are part of the context for the packet 
session, which should be transferred to ensure seamless transfer of the mobile 
terminars packet sessions to the new access router. 

(05] However, mobile applications, such as multimedia mobile Internet applications, 
typically require feature-rich IP-connectivity to the Internet Even though a mobile 
tenninal is able to exchange packets with. the network without any disruption due to 
handoff, the mobile terminal may not be able to immediately execute an Internet 
application upon the completion of the handofT. This is indeed the case when the 
application uses certain application-specific functionality from the network. 
Consequently, service disruption may occur despite having seamless IP connectivity 
if the application-specific functionality is not relocated at the time of the mobile 
terminal's IP-level handoff. Appropriate mechanisms may be required to provision or 
re-provision the application-specific functionality in a new network domain after the 
handoff so that the application continues to operate seamlessly for the mobile 
tenninal. 
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SUMMARY OF THE INVENTION 

[06) The present invention provides for relocation or provision of application-specific 
functionality required by Internet applications executing on a mobile tenninal (mobile 
node) at the time of terminal's network layer handoff. Entities that may participate in 
this process of relocation or provision of application-specific functionalities may 
include access routers, gateway routers and the entities providing the application 
specific functionalities such as transcoding proxies, performance enhancing proxies 
(PEPs), security gateways, location servers etc. Application-specific, functionality as 
used herein generally refers to functional requirements of an application for one or 
more sessions involving the application and may include requirements of the 
application or requirements of a session involving the application. Information about 
application-specific functionality is included in an application context. Thus, 
application context as used herein generally refers to information about functional 
requirements of at least one application involving at least one session (e.g. bandwidth 
requirements for a session, media format for a session, media formats acceptable for 
the application). 

(07] The relocation or provision of the application-specific functionalities with a network 
layer-level handoff (e.g. an IP-level bandofO enables the mobile terminal to 
seamlessly operate an application even in the light of network layer handoff. This is 
achieved by first registering the application context with a current access router, 
transferring the application context from one access router to another at the time of 
handoff, and taking appropriate steps to relocate or provision the application specific 
or session specific functionality. This is in contrast to requiring the mobile tenninal 
and the source to perform an entire protocol exchange from scratch for the new access 
point 

[08] In one embodiment of the invention, before a mobile tenninal handoff, a mobile 
terminal constmcts an application context for a session and registers the context with 
the current access router. The current access router informs a new access router about 
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the application context for the session. Subsequently, the new access router evaluates 
the application context, and if necessary, discovers a network entity that can support 
the application. According to one aspect, the netwoiic entity may be a transcoder 
proxy server that receives data bom the new access router, modifies the data, and 
returns the modified data to the new access router. According to another aspect, the 
network entity may receive data for the session from a gateway router that filters 
session data and forwards it to the network entity. The network entity subsequently 
modifies the data and returns the modified data to the new access router. 

[09] In other embodiments of the invention, computer-executable instructions for 

implementing the disclosed methods are stored on computer-readable media. Other 
features and advantages of the invention will become apparent with reference to the 
following detailed description and figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

(10] FIG. 1 shows an architecture that supports an application context transfer during an 
IP-level handoff of a mobile terminal according to one embodiment of the invention; 

{11] FIG. 2 shows a functional diagram of the mobile terminal of FIG. 1; 

[12] FIG. 3 shows a mobile terminal executing a sample video streaming application over 
a current IP session according to one aspect of the invention; 

[13] FIG. 4 shows a functional diagram of an access router in accordance with an 
embodiment of the invention; 

[14] FIG. 5 shows a fimctional diagram of a proxy server in accordance with an 
embodiment of the invention; 

■ 

[15] FIG. 6 shows a diagram of message flows between some components of the 
architecture of FIG. 1 for an application context transfer; 
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[16] FIG. 7 shows another architecture that suppoits an application context transfer during 
an IP-level handoff of a mobile terminal according to another embodiment of the 
invention; 

I17| FIG. 8 shows a diagram of message flows between some components of the 
architecture of FIG. 7 for an application context transfer; and 

[ISJ FIG. 9 shows a further architecture that supports an application context transfer 
during an IP-Ievel handoff of a mobile terminal according to a further embodiment of 
the invention, and also shows data paths fix)m a content source to the mobile terminal 
for different locations of the mobile terminal. 

DETAILED DESCRIPTION OF THE INVENTION 

(191 ^he invention may be embodied in various forms. Referring now to Fig. I, an 
architecture 10 that supports application context transf<^ is shown for an Internet 
session undergoing IP-level handoff according to an embodiment of the invention. As 
shown, one embodiment of the architecture 10 generally includes a mobile terminal 
12 within a current administrative domain 15, a current access router 14 in a current 
network 16, a new administrative domain 19, and a new access router 18 in a new 
access network 20. A session as used herein generally refers to a packet data stream 
between a mobile tenninal 12 and a content source 22. A communication application 
is supported over such a packet session. Seamless transition of the session's path in 
the network as mobile terminal 12 moves from cuirent administrative domain IS to 
new administrative domain 19 may be provided by a procedure as supported by 
Mobile IP (Mobile IP Specification: Internet Engineering Task Force RFC 3220 or 
draft-ietf-mobileip-ipv6-16.txt) and fast handoff. We refer to this transition as IP- 
level handoff. 

120) Before occurrence of the IP-level handofT, while mobile tenninal (MT) 12 is situated 
in a serving area within current administrative domain 15 served by current access 
network 16, content source (CS) 22 may generate a packet data stream that is 
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transmitted via a content source router 24 through a network 26 such as the Internet, 
to a gateway router 28 for current network 16. The data stream is subsequently routed 
through current network 16 to current access router 14 in communication with a base 
transceiver station (BTS) 30, and via a wireless channel (e.g. a wireless LAN in 
accordance with IEEE 802.11) to mobile terminal (MT) 12 (Mobile terminal 12 can 
be alternatively referred as a mobile node). Current access router 14 provides access 
to current network 16 for the current domain IS. In other embodiments, a plurality of 
access routers may support an administrative domain. Even though Figure 1 depicts 
only one base transceiver station, a plurality of base transceiver stations typically 
support an administrative region. The packet data stream can support a variety of 
services to mobile terminal 105 such as a streaming video multicast service, in which 
the packet data stream corresponds to a video stream. 

[21] Because MT 12 is mobile, it can move into new administrative domain 19 supported 
by a new base transceiver station 32 and conununicate with new access router 18. 
The new access router 1 8 is connected to new access network 20, which is connected 
with network 26 via a new gateway router 34. In accordance* with seamless IP-level 
handoff, for example through Mobile IP, the packet data stream from CS 22 is routed 
via network 26 though gateway router 34, new access network 20, new access router 
18, and BTS 32 to MT 12. The new path via new access network 20 for the packet 
data stream, however, may need to establish application specific service features 
before the session properly continues with MT 1 2. Without the transfer of application 
context information, this may require an entire protocol exchange being performed 
from scratch with CS 22 for new access network 20, which would not permit a 
substantially seamless transfer of an application session from the end user perspective. 
The present invention permits substantially seamless transfer of an application session 
by transferring the application context for the session. To assist with setting up 
application specific service features in support of the session, new access network 20 
according to one embodiment includes a network entity, such as proxy transcoder 
server 35. 
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122] For describing application context transfer for the application executing on the mobile 
terminal and the associated session, suppose, for example that MT 12 includes a video 
application (not shown), which receives streaming audio and video content from 
content soim^e 22. Refeiring now to Fig. 2, MT 12 in accordance with one 
embodiment generally includes a processor 36, and in communication with the 
processor, audio/video inputs 38, a keypad 40, a network interface 42, memory 44, 
and a display 46. The video application (not shown) is stored in memory 44 to 
provide processor 36 with instructions for engaging in a session with content source 
22 via network interface 42. Fig. 3 generally shows operation of MT 12 for such a 
video session, showing video content 48 on display 46. As shown in Fig. 4, a router 
according to an embodiment for the invention, such as routers 14, 18, 28 and 34, 
generally includes a processor 50, which is in communication with a first interface 52, 
a second interface 54, and memory 56. As shown in Fig. 5, a network entity 
according to one embodiment of the invention, such as proxy server 35, generaUy 
includes a processor 60 in conununication with at least one interface 64 and memory 
66. 

[23] Suppose now that a user of MT 12 desires to receive video content such as a HBO 
movie or a NFL sports clip from the content source 22. Suppose further that the user 
receives such content while MT 12 is in communication with access network 16, and 
that access network 16 communicates with MT 12 via current domain IS, which is a 
high bandwidth wireless local area network (WLAN). Suppose also that CT 22 uses 
session description protocol (SDP) as defined in RFC 2327, April 1998, to provide 
descriptive information for the session via a session initiation protocol (SIP) INVITE 
message as defined in RFC 2543, March 1999. MT 12 responds with 
acknowledgements regarding descriptions that it can accept, which would be accurate 
for the WLAN capabilities of current domain 15 and access network 16. The 
descriptions may include, for example, the type of media (voice and video), media 
format (e.g. MPEG^), bandwidth information, and Quality of Service (QoS) 
information. Referring to Fig. 6, which diagrams message flows according to an 
embodiment of the invention, these transmissions are shown as SIP transactions 70. 
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Based on the response by MT 1 2, the video session will begin according to bandwidth 
and QoS parameters applicable for communication via current access network 16. 

[24] Suppose now that the user desires to move MT 12 from the current WLAN 
administrative domain IS to a new administrative domain 19 in conununication with 
new access router 18 and new access network 20. Suppose also that the bandwidth in 
new administrative domain 19 is less than the WLAN administrative domain. This 
would typically be the case for example if the new administrative domain happens to 
be the outdoor cellular coverage. Because the session was established with higher 
bandwidth capabilities, the session may be unable to continue uninterrupted in its 
current state as regards resolution, speed of video motion, size of displayed pictures, 
color combinations, clarity of audio etc. Some of these parameters need to be changed 
so that, the video stream can fit in the new bandwidth constraints. To achieve this, 
prior to handoff from access router 14 to access router 18, MT 12 constructs an 
application context for the video session and registers 72 it with current access router 
14. It may create the application context, for example, from information obtained in 
the SDP descriptive information in the SJP INVITE message from CS 22 and from 
MT 12's subsequent response. In order to register the application context, MT 12 
formats the application context information into a pre-deteimined format that such 
access routers may accept. The pre-determined format may be according to a 
standard, such as one recommended by IETF. As an example, the standard format 
could be an object that could be used by an object-oriented application running on 
access routers 14, 18. Such object technologies, for example, may include Common 
Object Request Broker Architecture (CORE A), Distributed Component Object Model 
(DCOM), Simple Object Access Protocol (SOAP), Enterprise Java Beans (EJB), and 
Type Length Value (TLV). 

[25J After MT 12 creates and formats the application context for the video session, it 
registers 72 the context by transferring it to current access router 14, for example, via 
IP messaging. Such IP messaging may make use of protocols, for example, like 
Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), 
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Transmission Control Protocol (TCP), and Stream Control Transmission Protocol 
(SCTP). According to one aspect of the invention, the transfer of application context 
to current access router 14 occurs along with a handofT trigger message from MT 12, 
such as an indication of a reduction in signal strength. According to other aspects, the 
application context may be transferred at the beginning of the session, at handofT, or 
almost any other time therebetween. As shown in Fig. 6, registration 72 may occur at 
the beginning of the session prior to CS 22 sending 74 data to MT 12. Further, the 
application context may be periodically updated, such as when changes occur to 
sessions. Although discussed in combination with a video call scenario, the 
application context may include information about various types of applications and 
sessions and about multiple concurrent sessions and applications for MT 12. 

|26) As diagranuned in Fig. 6, after MT 12 transmits the application context to current 
access router 14, current access router 14 receives the application context and 
transmits 76 the application context to new access router 18. The timing of the 
transfer between access routers 14 and 18 may vary. For example, if MT 12 registers 
the application context at the beginning of the session, access router 14 may simply 
store the application context in memory 56 until it anticipates a handofT. It may 
anticipate a handofT based on the reception of a handofT trigger from MT 12, or based 
on other information, such as by GPS tracking information for MT 12. Conversely, if 
MT 12 registers the application context along with a handofT trigger, access router 18 
may immediately transfer the associated application context for MT 12 and its current 
sessions to new access router 1 8. Transfer 76 of the application context for MT 1 2 
and its sessions from router 14 to router 18 may occur via Internet conununications 
using IP messaging. 

[27] Upon reception of the application context, new access router 18 evaluates the 
application context to determine whether steps are necessary to introduce application- 
specific functionality for the session. It may do this by comparing the parameters 
contained in the application context with corresponding capabilities for transmissions 
via access networic 20 and communication capabilities for domain 19. For example. 
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in the video call scenario, access router 18 may evaluate the application context and 
determine that the bandwidth for communicating with MT 12 in new administrative 
domain 19 is less than the established session, as originally supported by broadband 
WLAN administrative domain IS. As such, access router 18, in accordance with 
program instructions stored in memory 56, may establish a relationship with network 
entity 3S to provide necessary application-specific functionality for the session. In the 
case of the video call session, nehvork entity 35 may be a transcoding proxy server 35 
that transforms the high bandwidth video into low bandwidth video appropriate for 
transmission over the new wireless link. 

[28] According to another aspect of the invention, current access router 18 may also 
initiate actions for providing application-specific functionality for the session after 
handoff to the new access router 18. This may be based on information about new 
access network 20 and new administrative domain 19 gained by protocols such as 
Candidate Access Router (CAR) Discovery Protocol (see draft-ietf-cardiscovery- 
issues-02.txt). As such, current access router 16 may make certain decisions prior to 
handoff for supporting the session after handoff, like determining transcoding 
requirements. 

[29J Referring now to Figs. 1 , 5, and 6, transcoding proxy server 35 includes a processor 
60 connected to at least one communication interface 62 and memory 64. According 
to instructions stored in memory 64, the processor may modify messages received via 
interface 62 as necessary to provide application-specific functionality for the session. 
For example, it may change the resolution, image size, color gradation, speed of 
motion or even coding format of the original content so that the bandwidth of the 
transformed content is suitable for the new administrative domain 19. In the video 
streaming scenario, it may modify streaming datagrams using compression 
technology known as MPEG-4 for Moving Pictures Experts Group version 4 into 
MPEG layer 2 (MPEG-2) datagrams. The streaming MPEG-4 datagrams, which 
typically include multiple streams and two-dimensional and three-dimensional scene 
components, may work well in a broadband environment like the WLAN of 
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administrative domain IS. They may not, however^ be appropriate for perhaps a 
slower connection, such as domain 1 9. By transcoding the datagrams into MPEG-2 
datagrams, which are more highly compressed into frames according to layer two 
levels, the video streaming may be seamlessly supported via new access router 1 8 and 
domain 19. The quality of the video content display 48 may degrade according to the 
MPEG-2 format, but the video streaming will continue seamlessly. In another 
embodiment, the coding format may still be maintained as MPEG-4, however quality 
of video may be reduced in the interest of supporting the content over the low 
bandwidth link. 

[30] When new access router 18 receives the application context, it may establish a 
relationship with network entity 35 in various ways. According to one embodiment of 
the invention, new access router may establish 78 a ping-pong tunnel 90 with 
transcoder 35. Ping-pong tunnel 90 is generally a two-way virtual path between new 
access router 18 and transcoder 35. As a virtual path, transmissions between new 
access router 1 8 and transcoder 35 are preferably encapsulated for tunneling (see e.g. 
RFC 2004, Minimal Encapsulation; and RFC 1701, ORE Tunneling). As such, new 
access router 1 8 may send packets to transcoder 35 over the tunnel, and transcoder 35 
may return packets containing modified or transcoded content to new access router 1 8 
over the tunnel. For example, as new access router 18 receives 80 datagrams from CS 
22 for the video call (which contain high quality video data in MPEG-4 format as 
initially established) it forwards 82 them to transcoder 35 via ping-pong tunnel 90. 
Transcoder 35 modifies the MPEG-4 video data contained in datagrams into MPEG-2 
video data (or MPEG-4 video data of reduced quality), encapsulates the transcoded 
video data into new datagrams and returns 84 them to new access router 18. New 
access router 18 then transmits 86 the datagrams containing this transcoded video 
content to MT 12. Accordingly, the content stream ftom CS 22 is not interrupted as 
MT 12 moves from domain 15 to new domain 19, and MT 12 is able to receive video 
content at a feasible rate to seamlessly maintain the video call. 
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(31] The ping-pong tunnel 90 also supports transcoding of messages in the reverse 
direction. Although not necessary in the video streaming scenario, MPEG*2 
datagran^s sent from MT 12 could also be sent to transcoder 3S via ping-pong tunnel 
90. Transcoder 35 may subsequently change the datagrams into an MPEG-4 format 
compatible with CS 22. This option is perhaps more practical for other scenarios 
where transcoder 35 changes other features of the datagrams, such as security features 
or QoS features. One such example is TCP PEP (e.g. see RFC 3 135), which needs to 
be present in the packet paths in both directions, i.e., in forward data path from CS 22 
to MT 12 as well as in reverse acknowledgement path fit>m MT 1 2 to CS 22. 

132] Application context transfer according to the present invention is versatile and may be 
applied to almost any type of application or session. For example, according to one 
embodiment of the invention, the application context may include information 
extracted from Hypertext Transfer Protocol (HTTP) messages. Suppose, for example, 
that a user in current administrative domain 15 is using MT 12 to surf the Internet. 
Suppose also that the user has downloaded a web page (not shown) that starts a 
certain application (not shown) on MT 12, such as a Hypertext Markup Language 
(HTML) document Other examples, among many, could include Extensible Markup 
Language (XML) documents or Synchronous Multimedia Integration Language 
(SMIL) documents. The information required to construct the application context 
could be included in such web pages sent by CS 22. For example, a certain 
application may require the location server in the access network to provide the 
location of MT 12 to CS 22. This enables CS 22 to tailor the content according to the 
location of MT 1 2. The need for location service for the application can be described 
by including an object in the downloaded web page to that effect. Here location 
service is the application-specific functionality provided by access network. 

f33I In some scenarios, MT 12 could decide by itself if the application-specific 
functionality is to be used from the network, and then it could construct the 
application context based on this information. For example, we can consider TCP 
performance enhancing proxies (PEPs) as described in RFC 3135 as the application- 
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specific functionality requested by the MT 12. MT 12 may register application 
context with access router 14 expressing need for TCP PEP. When MT 12 is attached 
to access netwoik 116, PEP may not be needed as the WLAN link has high bandwiddi 
and low error rate. However, when handed off to access router 118, TCP PEP may 
need to be introduced in the end-to-end data path to cater to low bandwidth and high 
error rate of wireless link in administrative domain 1 19. 

[34] Referring now to Figs. 7 and 8, architecture 110 that supports application context 
transfer for an Internet session during IP-level handofT of a mobile terminal in 
accordance with another embodiment of the invention is shown. Architecture 110 and 
the accompanying embodiment of the present invention, wherein like numerals refer 
to like features, generally includes the same aspects as previously discussed except as 
explained below. In keeping with the video streaming scenario, suppose that mobile 
terminal 112 moves from a current admihistrative domain IIS, where a video 
streaming session began using MEP-4 parameters and broadband WLAN 
communications with access router 1 14, to new administrative domain 1 19. Suppose 
further that according to the steps shown in Fig. 8, access router 1 14 is in the process 
of transferring 1 76 the application context for the video session to new access router 
118. 

(35] When new access router 118 receives the {^plication context, it evaluates the 
application context to determine what steps are necessary to provide application 
functionality for the session, which may include establishing a relationship with 
transcoder 135. According to one embodiment of the invention, new access router 
may establish 178 a deflection tunnel 190 fix>m gateway router 134 via transcoder 
135. Deflection tunnel 190 is generally a virtual path between a gateway router 134 
and new access router 118 via proxy transcoder server 135. Gateway router 134 as 
used herein generally includes a router that can provide filtering functions. It may be 
a primary path between access netwoik 1 20 and other networks, such as Internet 1 26. 
It could also be one of many routers along a pathway that packets in the video session 
pass, which may be tasked with filtering and tunneling packets for the session. 
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[36] According to instructions stored in memoiy 56 of access router 1 1 8, router 1 1 8 
communicates with gateway router 134 and transcoder proxy 135, such as through IP 
messaging, to establish deflection tunnel 190. Further, gateway router 134 and 
transcoder proxy 135 may also communicate to establish portions of deflection tuimel 
190. Once set up, gateway router 134 filters packets for the session and forwards 
them to proxy server 135 via a virtual path. The virtual path, for example, may 
include encapsulating session packets for routing to proxy server 135 as is known for 
tunneling techniques. Once packets are received and de-encapsulated by transcoder 
proxy 135, proxy 135 modifies the packets as necessary according to instructions 
from new access router 118 in concert with the application context of the session. 
Thus, transcoder proxy 135 transcodes data for the session to provide seamless 
application fimctionality for the session. After transcoding packets, proxy 135 
encapsulates and forwards the packets to new access router 118, which de- 
encapsulates the transcoded packets and forwards them to MT 112. 

[371 For example, according to the video streaming scenario, gateway router 1 34 receives 
1 80 datagrams fi-om CS 22 for (he video call, which as initially established contain 
video data encoded in MPEG-4 format. Gateway router 1 34 subsequently filters the 
datagrams for the session, encapsulates them, and forwards them to transcoder proxy 
135. Transcoder 135 de-encapsulates the datagrams and modifies the MP£G*4 video 
data into MPEG-2 video data or maintains MPEG-4 coding format but reduces the 
quality of video content. It subsequendy encapsulates the transcoded content into 
new datagrams and forwards 184 them to new access router 118. New access router 
1 1 8 then de-encapsulates the datagrams containing transcoded content and transmits 
186 them to MT 1 12. Accordingly, the content stream from CS 122 is not interrupted 
as MT 112 moves fit>m domain 115 to new domain 119, and MT 112 is able to 
receive datagrams containing transcoded content at a feasible rate to seamlessly 
maintain the video call. 

[38] The deflection tuimel 190 further supports transcoding of messages in the reverse 
direction. Although not necessary in the video call scenario, MPEG-2 datagrams sent 
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from MT 112 could also be sent to transcoder 135 via deflection tunnel 190. 
Transcoder 135 may subsequently change the datagrams into an MPEG-4 fonnat 
compatible with CS 122. This option is peiiiaps more practical for other scenarios 
where transcoder 135 changes other features of the datagrams, such as security 
features or QoS features. One such example is TCP PEP, which needs to be present in 
ihe packet paths in both directions, i.e., in forward data path as well as 
acknowledgement path. 

|39] Referring now to Fig. 9, architecture 210 is shown that supports application context 
transfer for an Internet session during IP-level handoff of a mobile terminal according 
to a further embodiment of the invention. Architecture 210 and the accompanying 
embodiment of the present invention, wherein like numerals refer to like features, 
generally includes the same aspects as previously discussed except as explained 
below. Generally, architecture 210 includes embodiments of the ping-pong tunnel 90 
and the deflection tunnel 190. In keeping with the video streaming scenario, suppose 
that mobile terminal 112 moves from a current administrative domain 215, where a 
video streaming session began using MEP-4 parameters and broadband WLAN 
commum'cations with access router 214, to new administrative domain 219, and 
eventually to another administrative domain 221. As MT 312 moves between 
administrative domains, the application context for the session is transferred initially 
from access router 214 to access router 218, and then from access router 218 to 
another access router 217 for domain 221. After receiving the application context, 
access router 218 evaluates the application context and establishes a ping-pong tunnel 

290 to provide application-specific functionality for the session. In contrast, after 
receiving the application context, access router 217 establishes a deflection tunnel 291 
to support application functionality. Both ping-pong tunnel 290 and deflection tunnel 

m 

291 are not exclusive options for supporting application functionality, and either or 
both may be used by same or different access networks. 

[40] While the present invention has been described in connection with the illustrated 
embodiments, it will appreciated and understood that modifications may be made 
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without departing hom the true spirit and scope of the invention. In particular, the 
invention applies to any mobile terminal and architecture for providing service 
provisioning through application context transfer. 
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lAVe claim: 

1 . A mobile terminal adapted to participate in transferring an application context 
to enable a substantially seamless network level handoff of an application executing on the 
mobile terminal across access networks, the terminal comprising: 

a communications interface; and 

a processor communicating through the communications interface, the processor 
configured to perform the steps of: 

(a) constructing an application context for a session involving the application 

executing on the mobile terminal; and 

(b) registering the appUcation context with a current access router in 
communication with the mobile terminal. 

2. The mobile terminal of claim 1, wherein the processor is configured to 
perform the further step of (c) sending a handoff trigger to the current access router to 
transfer the application context to a different access router. 

3. The mobile terminal of claim 1, wherein the application context comprises 
information about a plurality of sessions involving the application. 

4. The mobile terminal of claim I, wherein the application comprises a plurality 
of applications executing on the mobile terminal and the application context comprises 
information about a plurality of sessions involving the plurality of applications. 

5. The mobile terminal of claim 1, wherein the application context comprises 
information about the session. 

6. The mobile terminal of claim 5, wherein the application context information 
comprises Session Description Protocol (SDP) information. 
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7. The mobile terniinal of claim 5, wherein the application context infonnation 
comprises information selected from the group consisting of media coding information, 
Quality of Service (QoS), and bandwidth information. 

8. The mobile terminal of claim 7, wherein the media coding information is 
selected from the group consisting of MPEG-2 and MPEG-4. 

9. The mobile terminal of claim 5, wherein the application context information 
comprises infonnation extracted from a downloaded Hypertext Transfer Protocol (HTTP) 
web page associated with the session. 

10. The mobile terminal of claim 9, wherein the extracted information comprises 
data within an object in the downloaded web page. 

11. The mobile terminal of claim 9, wherein infonnation to construct die 
application context is included in the downloaded web page using a marlcup language. 

12. The mobile terminal of claim ]1» wherein the markup language is selected 
from the group consisting of Hypertext Markup Language (HTML), Extensible Markup 
Language (XML), and Synchronous Multimedia Integration Language (SMIL). 

13. The mobile terminal of claim 1» wherein step (b) comprises the step of 
formatting the application context into a format for transmission to the current access router. 

14. The mobile terminal of claim 13, wherein the format for the application 
context comprises an object. 

15. The mobile terminal of claim 14, wherein the object conforms with an object 
model selected from the group consisting of Common Object Request Broker Architecture 
(CORBA), Distributed Component Object Model (DCOM), Simple Object Access Protocol 
(SOAP), Enterprise Java Beans (EJB), and Type Length Value (TLV) format. 
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16. The mobile terminal of claixn 1, wherein step (b) comprises the step of 
transmitting the application context to the current access router. 

17. The mobile terminal of claim 16, wherein the transmission of application 
context is performed using a protocol for transferring messages between nodes In an Internet 
protocol (IP) network. 

18. The mobile terminal of claim 17» wherein the protocol is selected from the 
group consisting of Internet Control Message Protocol (ICMP), User Datagram Protocol 
(UDP), Transmission Control Protocol (TCP), and Stream Control Transmission Protocol 
(SCTP). 

19. An access router adapted to participate in transferring an application context 
of a session involving a mobile terminal to enable a substantially seamless network level 
handoff of an application executing on the mobile terminal across access networks, the access 
router comprising: 

« 

a first communications interface that communicates with the mobile terminal; 
a second interface in communication with another access router; and 
a processor in communication with the first and second interfaces, the processor 
configured to perform the steps of: 

(a) receiving an application context from the mobile terminal in 
communication with the first communications interface; and 

(b) transmitting the application context to the another access router via the 
second interface. 

20. The access router of claim 19, wh^ein step (b) is performed in anticipation of 
an impending handoff of the mobile terminal. 



21. The access router of claim 20, wherein the anticipation of an impending 
handoff comprises reception of a handoff trigger from the mobile terminal. 

- 19- 



wo 03/091900 



PCT/IB03/01629 



22. An access router adapted to participate in transferring an application context 
of a session involving a mobile terminal to enable a substantially seamless network level 
handofTof an application executing on the mobile terminal across access networks, the access 
router comprising: 

a first communications interface that communicates with the mobile terminal; 
a second interface in communication with an originating access router; and 
a processor in communication with both of the interfaces, the processor configured to 
perform the steps of: 

(a) receiving an application context from the another access router via the 
another interface; and 

(b) evaluating the application context to determine whether steps are 
necessary to ensure a substantially seamless continuation of the session after the 
handofT. 

23. The access router of claim 22» wherein the application context comprises 
parameters for the session and step (b) comprises the step of (c) comparing the parameters 
with corresponding capabilities of the access network associated with the access router. 

24. The access router of claim 23, wherein the parameters for the session are 
selected from the group consisting of media coding information. Quality of Service (QoS), 
and bandwidth information. 

25. The access router of claim 24, wherein the media coding information is 
selected from the group consisting of MPEG-2 and MPEG-4. 

26. The access router of claim 22, wherein in response to step (b), the processor 
performs the further step of (c) establishing a relationship with a network entity for 
processing data transferred as part of the session. 
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27. The access rouler of claim 26, wherein the network entity comprises a proxy 

server. 

28. The access router of claim 27, wherein the proxy server comprises a 
transcoder. 

29. The access router of claim 28, wherein step (c) comprises' the step of 
informing the transcoder about the transcoding parameters for the session. 

30. The access router of claim 29, wherein the transcoding parameters comprise 
bandwidth reduction of the session aAer handolT. 

31. The access router of claim 26, wherein the processor performs the farther 
steps of: 

(d) receiving communication packets associated with the session via one of the 
interfaces; and 

(e) sending the conmiunication packets to the network entity. 

32. The access router of claim 3 1 , wherein step (e) comprises the steps of: 
(Q encapsulating the communication packets; and 

(g) transmitting the encapsulated packets to the network entity. 

33. The access router of claim 31, wherein the processor performs the further 
steps of: 

(f) receiving encapsulated versions of the communication packets from the 
network entity; and 

(g) de-encapsulating the encapsulated versions. 

34. The access router of claim 22, wherein in response to step (b), the processor 
performs the further step of (c) creating a communication path between a gateway router and 
the access router via a network entity for the session. 
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35. The access router of claim 34, wherein step (c) comprises the steps of: 

(d) communicating with the networic entity server to create an entity-to-access 
router communication path between the network entity and the access router for the session; 
and 

(e) communicating with the gateway router to create a gateway-to-entity 
communication path between the gateway router and the network entity for the session. 

36. The access router of claim 35, wherein step (e) comprises the further stq> of 
instructing the gateway router to filter communication packets received from outside the 
access network for the session and to route the filtered communication packets to the access 

« 

router via the network entity. 

37. The access router of claim 35, wherein the commimication paths of steps (d) 
and (e) comprise tunnels. 

38. The access router of claim 34, wherein the processor performs the further 
steps of: 

(d) receiving conmiunication packets associated with the session from the 
network entity via the another interface; and 

(e) sending the conmnmication packets to the mobile terminal via the mobile 
terminal conmiunications interface. 

39. The access router of claim 38, wherein step (d) comprises the steps of: 

(f) receiving encapsulated versions of the communication packets; and 

(g) de-encapsulating the encapsulated versions. 

40. A networic entity adapted to participate in enabling a substantially seamless 
network level handoff of an application executing on a mobile terminal across access 
networks for a session, the networic entity comprising: 

a network communications interface in communication with an access router; and 
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a processor in communication with the interface, the processor configured to perform 
the steps of: 

(a) receiving instructions from the access router for managing 
communication packets related to the session in accordance with the application 
context; 

(b) receiving conmiunication packets related to the session; and 

(c) managing the communication packets in accordance with the 
instructions. 

41. The network entity of claim 40, wherein step (b) comprises the step of de- 
encapsulating the received conmiunication packets. 

42. The network entity of claim 40, wherein the network entity comprises a proxy 

server. 

43. The proxy server of claim 42, wherein the proxy server comprises a 
transcoder. 

44. The network entity of claim 43, wherein step (c) comprises the steps of: 

(1) modifying data contained in the conmiunication packets into a fonnat 
compatible with the mobile terminal; 

(2) putting the formatted data into other communication packets; and 

(3) sending the other communication packets to the access router. 

45. The network entity of claim 44, wherein step (2) comprises the step of 
encapsulating the other conmiunication packets for transmission to the access router. 

46. A method .for transferring an application context for a session involving a 
mobile terminal to enable a substantially seamless network level handoff of an application 
executing on the mobile terminal, the method comprising: 
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(a) constructing an application context for a session involving an application 
executing on the mobile tenninal; and 

(b) registering the application context with a current access router in 
communication with the mobile terminal. 

47. A method for transferring an application context for a session involving a 
mobile temoinal to enable a substantially seamless network level handoff of an application 
executing on the mobile terminal, the method comprising: 

(a) receiving the application context at a current access router in communication 
with the mobile terminal; and 

(b) transmitting the application context to another access router. 

48. A method for transferring an application context for a session involving a 
mobile temiinal to enable a substantially seamless network level handoff of an application 
executing on the mobile terminal, the method comprising: 

(a) receiving at an access router the application context firom another access 
router; and 

(b) evaluating the application context to determine whether steps are necessary to 
ensure a substantially seamless continuation of the session after handoff. 

49. The method of claim 48, wherein, in response to step (b), the method further 
comprises the step of (c) establishing a relationship with a network entity for processing data 
transferred as part of the session. 

50. The method of claim 49, further comprising the steps of: 

(d) receiving commwucation packets associated with the session; and 

(e) sending the communication packets to the network entity. 

51. The method of claim 48, wherein in response to step (b), the method further 
comprises the step of (f) creating a communication path between a gateway router and the 
access router via a network entity for the session. 
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52. The method of claim S 1 , further comprising the steps of: 

(g) receiving communication packets associated with the session from the 
network entity; and 

(h) sending the communication packets to the mobile terminal. 

53. A method for transferring an application context for a session involving an 
application executing on a mobile terminal to enable a substantially seamless network level 
handoff of the mobile terminal, the method comprising: 

(a) receiving instructions from an access router for managing communication 
packets related to the session; 

(b) receiving communication packets related to the session; and 

(c) managing the communication packets in accordance with the instructions. 

54. The method of claim 53, wherein step (c) comprises the steps of: 

(d) modifying data contained in the communication packets into a format 
compatible with the mobile terminal; 

(e) putting the formatted data into other conununication packets; and 

(f) sending the other communication packets to the access router. 

55. A computer-readable medium containing instructions for transfeiring an 
application context for a session involving an application executing on a mobile terminal to 
enable a substantially seamless network level handoff of the mobile terminal, comprising 
instructions that cause the mobile terminal to perform the steps of: 

(a) constructing an application context for a session involving the mobile 
terminal; and 

(b) registering the application context with a current access router in 

« 

communication with the mobile tenninal. 
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56. A mobile terminal adapted to participate in transferring an application context 
to enable a substantially seamless network level handoff of an application executing on the 
mobile terminal across access networks, the temiinal comprising: 

a communications interface; and 

a processor conmiunicating through the communications interface, the processor 
configured to perform the steps of: 

(a) constructing an application context for a streaming video session 
involving the mobile terminal, the streaming video session comprising data having a 
bandwidth and coding format, the application context comprising information about 
the session, the information comprising the bandwidth and coding format; 

(b) formatting the application context into a format for transmission to the 
current access router; 

(c) transmitting the application context to the current access router^ and 

(d) sending a handoff trigger to the current access router to transfer the 
application context to a different access router. 

57. An access router adapted to participate in transferring an application context 
of a streaming video session involving an application executing on a mobile terminal to 
enable a substantially seamless network level handoff of the application on the mobile 
terminal across access networks, the streaming video session having a first bandwidth, the 
access router comprising: 

a first communications interface that communicates with the mobile terminal; 
a second interface in conununication with an originating access router; and 
a processor in communication with both of the interfaces, the processor configured to 
perform the steps of: 

(a) receiving an application context from the another access router via the 
another interface; and 

(b) evaluating the application context to determine whether steps are 
necessary to ensure a substantially seamless continuation of the session after the 
handoff; 
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(c) establishing a relationship with a network entity for processing data 
transferred as part of the session, the processing comprising transcoding the streaming 
video data from a first bandwidth to a second bandwidth; 

(d) receiving communication packets containing data with a first 
bandwidth associated with the streaming video session via one of the interfaces; 

(e) encapsulating the communication packets; 

(f) transmitting the encapsulated packets to the netwoik entity; 

(g) receiving encapsulated packets containing transcoded data from the 
network entity; 

(h) de-encapsulating the transcoded packets, the transcoded data having a 
second bandwidth; and 

(i) transmitting the packets containing transcoded packets to the network 
terminal. 
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